@jorgemanrubia I think I am misunderstanding the use case for applications to utilize a Turbo-specific fetch (1. above).

Why would an application need to make a request with an X-Turbo-Request-Id header? Even if they were able to import and utilize the Turbo-extended fetch, how would they application pass the HTTP response back to Turbo in a way that is compatible with Turbo Drive?

If they're submitting a request outside of Turbo.visit or HTMLFormElement.requestSubmit(), what risks would an internal fetch guard against?

@seanpdoyle because that way the application makes sure that the request id is registered by Turbo internally. So that, if a "refresh" stream action is broadcasted, and if it carries information about the "request id that originated it", Turbo can determine if it was self-originated and, in that case, ignore it.

Practical case: you have a Drag & Drop system that relies on window.fetch from a stimulus controller to update stuff. You have configured the server the involved models to broadcast "page refreshes" on changes. If you drop an element, you don't want to get a broadcasted "page refresh" from the same request that you originated.

In the general case, you are interested in all the broadcasted "page refreshes" except the ones that you originate. The vast majority of your page refreshes will come via Turbo actions, but not necessarily all of them, since using window.fetch is still relatively common in certain circumstances. That's the problem we're trying to solve here.

you don't want to get a broadcasted "page refresh" from the same request that you originated.

Ahhh, so the header is less about fetch's integration with HTTP, and more about guarding against background broadcasts over Web Sockets. That's something that was missing from my perspective on the problem.

With that in mind, is there a difference in outcomes between Turbo support for something like:

import { fetch } from "@hotwired/turbo"

fetch("/my-path", { ... })

versus something like:

import { withTurboHeaders } from "@hotwired/turbo"

window.fetch("/my-path", withTurboHeaders({ ... }))

// or maybe
import { FetchRequest } from "@hotwired/turbo"

window.fetch("/my-path", FetchRequest.prepare({ ... }))

Both scenarios require awareness that Turbo does something special with handling fetch.

@seanpdoyle not in outcomes but in ergonomics from the caller side, imo. Also, the first form's encapsulation is higher, hiding away the fact that internally it's manipulating the request headers.

Hello

Thanks for all the work going on, it looks really promising.

I wanted to share a few thoughts:

import { fetch } from "@hotwired/turbo"

I personally think having a custom fetch option coming from Turbo will add lots of confusion at the end.

I have been really enjoying the @rails/request.js library so far. The API is nice with lots of small goodies. Out of all the fetch libraries that I have been using, I think it has the best API.

in #1019 (comment) @marcelolx proposed some help to make Rails/request.js Turbo compatible. My favorite solution would be to be able to use this package for all my fetch-related actions.

Therefore project NOT using @rails/request.js, I would second @seanpdoyle suggestion for something like that.

import { withTurboHeaders } from "@hotwired/turbo"

window.fetch("/my-path", withTurboHeaders({ ... }))

This makes it clear that it is not the preferred option. The preferred option would be documented by using request.js.

And for Rails/request.js let's make sure this works out of the box from the standard fetch library provided by Rails.

Hey @adrienpoly, +1 to make @rails/request.js the preferred option for manual fetch operations. We can make sure we document that clearly in the docs also, and we can improve the compatibility with Turbo in the process.

I don't agree with making the not-preferred option less ergonomic though.

The issue I see with exposing this new custom fetch from Turbo as a public API is that it will make it harder down the road to unify Turbo and Request.js. To me, it should remain a private API inside Turbo or come from request.js

When I saw Request.js for the first time, I saw it as an extraction of Turbo internal fetch and thought the plan was to ultimately replace Turbo internal fetch with request.js. I am sure there are quite a few differences in both implementations but last time I looked there was also a lot of duplication in both code bases.

IMHO, the most comprehensive API would be

import { get, put, post, delete  } from "@hotwired/turbo"

and those get, put, post, and delete would be coming from request.js

Closing due to comments above: #1025 (review).